View AN1071_3296139.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

AN1071/0102 1/17 AN1071 application note half duplex usb-to-serial bridge using the st72611 usb microcontroller by usb application team introduction this application note describes how to develop a bridge that allows a rs232 peripheral to be connected to a host computer through a usb connection. communication with the host computer is based on the hid (human interface device) usb protocol, permitting a maximum speed of 800 bytes/sec with a usb low speed device. it makes development of the user host application easy by using the native hid driver and func- tions library provided by the os (operating system). a reference firmware has been developed by stmicroelectronics based on a low-cost, low- pin-count usb microcontroller such as the st72611 or st72623. it can be obtained by con- sulting your st sales office. a demonstration board has also been developed: it can be obtained by consulting your st sales office, and the schematic is given in this document. 1
2/17 table of contents 17 1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 system features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 usb communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 serial communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1 from usb to rs232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.2 from rs232 to usb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 hardware implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 software implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1 initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2 main loop tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2.1 check suspend flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2.2 usb standard transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2.3 check data from usb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2.4 check feature report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2.5 fill usb buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2.6 set handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3 interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3.1 usb interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3.2 port b external interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1 data buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1.1 buffer_rx_ptr pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1.2 buffer_rx_ptr pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1.3 overflow condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 handshaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2.1 rs232 port data transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2.2 rs232 port data reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 rs232 port communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2 data transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.3 data reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.3.1 principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.3.2 sampling the 1st data bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3/17 half duplex usb-to-serial bridge using the st72611 usb mcu 1 system features 1.1 usb communication usb communication with the pc host is implemented in accordance with the hid (human in- terface device) class specification. this specification uses the following pipes: n control pipe (endpoint 0) is mainly used to enumerate the device. ( set_feature command is also used to set some device parameters). n interrupt in pipe (endpoint 1) for data sent to the host n interrupt out pipe (endpoint 2) for data received from the host if the host computer does not support the interrupt out pipe (windows 98), the set_output command (control pipe) is used instead to transfer data from host to device. communication is based on interrupt in/out pipes, which implies a fixed 8-byte packet size. therefore it is necessary to provide information about the number of meaningful or relevant bytes contained in this 8-byte data packet, as described below: consequently, the in and out reports have the following structure: nb: number of significant bytes 1.2 serial communication the proposed solution features 5-pin half duplex communication, where the usb-to-serial bridge is behaves as a dte (data terminal equipment) as defined in the rs232 specification. in this configuration, a cts/rts handshake is implemented as flow control. the baud rate is configurable up to 56700 baud and a fixed 10-bit frame format is used. how- ever, different frame formats or flow control can easily be implemented by slightly modifying the firmware. 01234567 nb data data data data data data data 2
4/17 half duplex usb-to-serial bridge using the st72611 usb mcu 1.3 flow control a basic flow control system has been used in order to compensate the asynchronisms and speed differences between the usb and the rs232 port. 1.3.1 from usb to rs232 the basic principle is to keep the receiving endpoint disabled until the rs232 transfer is com- pleted. this ensures no data is sent by the host until the device has correctly processed the previous data. a second (and independent) flow control level can be implemented on the rs232 port side to check that the device connected is ready to receive data. it is based on cts signal monitoring by the bridge, and it must be noted that due to the relative speed differences between rs232 and usb, this protection is rarely activated. 1.3.2 from rs232 to usb this case is more critical since the most common rs232 baud rates are higher than the low speed usb bandwidth. two flow control methods can be considered: 1. use a temporary circular buffer in the bridge. 2. use handshaking (hardware or software) between the bridge and the serial port device if the buffer gets full. several implementations are possible and the choice depends on the rs232 port communi- cation characteristics: speed, total data amount, time between bytes or byte packets. by default, the proposed solution includes the circular buffer whereas hardware handshaking can be enabled or disabled. in case the buffer overflows (hardware handshaking disabled), a buffer overflow message is sent to the host through the following report. 01234567 aa ff ff ff ff ff ff ff
5/17 half duplex usb-to-serial bridge using the st72611 usb mcu 2 hardware implementation to interface with a rs232 line, a level translator is required. in order to match the usb spec- ification the level translator must be specified at least in the 4.05-5.25v range. in case of a common 5-pin rs232 configuration, the st3232 (2 receivers, 2 transmitters) can be used, while the st3243 is needed for a complete rs232 configuration (5 receivers, 3 transmitters). the example provided refers to a 5-pin implementation. the level translator power consumption can be turned off under software control in order to match the usb suspend mode behaviour. when using the st3232, this is done by turning-off its vcc supply through a pnp transistor controlled by the pa2 i/o pin on the microcontroller. if the st3243 is used instead, software control has to be adapted to activate the power-down mode of the st3243. see the schematic and bill of materials in the appendix for more details.
6/17 half duplex usb-to-serial bridge using the st72611 usb mcu 3 software implementation 3.1 architecture the firmware is built based on the usb library v4.x for st7 usb low speed devices. this li- brary contains all the necessary functions to handle usb communication, including hid pro- tocol requests. a key benefit of this library is that some variables are shared by the user application and the usb event manager. this makes the software architecture quite simple, as shown below. it is highly recommended to look at application note an1325 for a detailed description of the shared variables. 3.1.1 initialization at the beginning, the firmware initializes the both usb and the application. the init_app_hw() function, in my_init.c allows users to initialize the program as well as the hardware. after the initialization, the firmware enters the usb polling main loop. main loop initialize application variables and hardware falling edge interrupt serial data sampling & transfer to buffer suspend mode resume if usb activity starts after suspend begin initialization data arrived from usb send data to serial buffer going to full set rts usb buffer empty send data to usb set feature set baud rate disable or enable ep0 requests set buffer limit
7/17 half duplex usb-to-serial bridge using the st72611 usb mcu 3.1.2 main loop tasks 3.1.2.1 check suspend flag if (usblibstatus & usb_suspend) the suspend flag ( usb_suspend ) in the usblibstatus variable is set, this indicates there has been no start of frame (sof) from usb host for more than 3ms. in this case the firmware should enter suspend mode to reduce power consumption (in our hardware example, this turns-off the st3232 supply). 3.1.2.2 usb standard transfer handle_usb_events(); if (usblibstatus & app_request) { handle_app_requests(); enable_status_stage(); } if the suspend flag is not set, the firmware will process the standard transfer on endpoint 0. 3.1.2.3 check data from usb //test if some data arrived on ep2 out if ((usbep2rb & 0x30) == 0x20) { while (valbit (padr, cts)) {asm nop;} sendserial (ep2outbuffer[0],2); set_ep_ready(2, ep_out, 8); } check whether data is received from usb. if yes, the firmware disables all interrupts and then sends the data to the rs232 port. 3.1.2.4 check feature report if((status & setfeat)&&(test_ep_ready(0,ep_out))) { if(ep0outbuffer[0] == 0) } if a feature report is received, the firmware will configure itself according to the feature report. the following features can be set: baud rate: 4800, 9600, 19200, 38400, 57600. handshake: disabled or enabled buffer limit: a value set to define the buffer full condition.
8/17 half duplex usb-to-serial bridge using the st72611 usb mcu 3.1.2.5 fill usb buffer if (test_ep_ready(1, ep_in)) //checks usb buffer ready send_usb(); //copy data to usb buffer the firmware checks first whether endpoint 1 is ready for transmission: this means the pre- vious in token has been processed and the usb buffer can be safely overwritten. secondly it checks if any data are available in the ring buffer. if so, the following sequence is applied: C copy bytes from the ring buffer to the endpoint buffer C set the endpoint to ready state with the setepready() routine from the usb library as a result the data copied are automatically transferred to the host (by the usb embedded state machine) the next time an in token occurs. 3.1.2.6 set handshake if (program_status & use_handshake) { } if handshaking is enabled, the firmware will use hardware handshaking. 3.1.3 interrupts two interrupt sources have been used in this firmware: the usb interrupt and the port b ex- ternal interrupt. 3.1.3.1 usb interrupt the usb interrupt sets flags according to the usb events. the event processing is done within the main loop. please refer to application note an1325 for more details about the usb interrupt. as explained in the rs232 data reception section, the usb interrupt routine of the usb li- brary has been slightly modified to monitor the rx pin. 3.1.3.2 port b external interrupt data reception is based on an interrupt routine triggered by a falling edge on the rx pin. the falling edge corresponds to the transition idle to start bit. the interrupt routine manages the serial data sampling, its transfer to the internal data buffer and the update of pointers to this buffer.
9/17 half duplex usb-to-serial bridge using the st72611 usb mcu 3.2 flow control 3.2.1 data buffer the proposed firmware is based on a ring buffer approach for data transfer rs232 to usb. its size is defined as 128 bytes by the buffer_size constant in user_def.h. also, buffer_mask specifies the buffer mask. the buffer size and limit have the following values unless the program is modified: 3.2.1.1 buffer_rx_ptr pointer this buffer points to the data received on the rs232 port. when a data has been received, it is stored in the buffer at the location pointed to by buffer_rx_ptr and its value is incremented by 1. when it reaches the size of the buffer, the pointer is reset to its initial value. 3.2.1.2 buffer_rx_ptr pointer when a data in token is received, the firmware moves some data from the ring buffer (buffer_tx_ptr) to the ep dma buffer for transmission. the amount of data fetched depends on the difference (delta) between the rx pointer and the tx pointer. if the difference is larger than 7, only 7 bytes will be fetched and sent to the usb. the buffer_tx_ptr will then be incre- mented by 7. if delta is less than 7 then delta bytes w ill be fetc hed and sent, and the buffer_tx_ptr will be incremented by delta. 3.2.1.3 overflow condition if the rs232 port transfer rate is higher than the usb transfer rate, the buffer_rx_ptr pointer might be incremented much faster than the buffer_tx_ptr. an overflow occurs when buffer_rx_ptr is equal to buffer_tx_ptr. this check is performed in the reception interrupt routine. buffer size 16 32 64 128 256 buffer mask 0x0f 0x1f 0x3f 0x7f 0xff direction buffer_tx_ptr buffer_rx_ptr
10/17 half duplex usb-to-serial bridge using the st72611 usb mcu 3.2.2 handshaking the safest way to avoid buffer overflow is to enable a handshaking system on the rs232 port. 3.2.2.1 rs232 port data transmission the principle is to send data on the rs232 port only when the cts signal is asserted (active low). uart_polling in uart.c. if ((usbep2rb & 0x30) == 0x20) //test if some data arrived { while (valbit (padr, cts)) {asm nop;} // check handshake //if yes, send the ep2outbuffer[0] bytes to rs232 sendserial (ep2outbuffer[0], 2); //sets back the ep ready set_ep_ready(2, ep_out, 8); } the code while (valbit (padr, cts)) {asm nop;} checks the level of cts. a high level in- dicates the device is not able to receive data. therefore, the firmware waits until cts be- comes low before reenabling the endpoint 2 for usb data out transfer.
11/17 half duplex usb-to-serial bridge using the st72611 usb mcu the above plot demonstrates the detection of cts. in the plot, the upper channel is the data, received by the usb, sent from the firmware through rs232. the lower channel is the state of cts. the cts signal is generated manually. 3.2.2.2 rs232 port data reception the principle is to assert the rts signal (active low) only if the internal buffer is able to re- ceive new data. if, for any reason, the interfacing device does not take it into account, a more complex data flow has to be put in place. as the connected device may effectively stop sending data only after purging its own transmis- sion buffer (16 bytes on most pc computers), the rts signal setting must be done before the buffer is completely full: therefore the firmware sets the rts when the buffer is 75% full. here are the two conditions for setting the rts and therefore disabling the data transfer on the serial port: (buffer_tx_ptr>buffer_rx_ptr) &&(buffer_tx_ptr-buffer_rx_ptr) 12/17 half duplex usb-to-serial bridge using the st72611 usb mcu its value can be modified by using a set_feature report. in the above plot, the upper channel is the data sent to the bridge on the serial port while the lower channel is the state of rts.
13/17 half duplex usb-to-serial bridge using the st72611 usb mcu 3.3 rs232 port communication 3.3.1 overview the uart required for rs232 communications is emulated by firmware in order to use a basic and cost effective microcontroller, the st72611. as a consequence, all timings are han- dled by software wait loops. as already mentioned, the proposed firmware has the following features: C configurable bit rate from 4800 up to 57600 bps - default 9600. C 10-bit frame format (1 start bit, 8 data bits, 1 stop bit) C half duplex in this implementation we will use the pb.0 i/o port on the st72611 mcu for tx and the pb.7 for rx. however, the pin could be changed depending on the application. to change tx or rx within port b, simply change the tx and rx constants in user_def.h. 3.3.2 data transmission before transmitting data, interrupts are disabled. in fact, if an interrupt occurs during the trans- mission, the waiting loop timings will be incorrect. when the application firmware has to send some data, the sendserial routine is called. the parameter of this routine is the number of bytes to transmit and the endpoint number. the sendserial routine first generates the start bit, then performs 8-bit operations, separated by a timing loop. 0 1 2 3 4 5 6 7 start bit data stop bit 0 1 2 3 4 5 6 7 call the send routine 1 bit time
14/17 half duplex usb-to-serial bridge using the st72611 usb mcu /* start bit */ bres pbdr, #tx //tx is the rs232 output pin ld a, #val1 //4 cycles looptx d : dec a //3 cycles cp a, #0x00 //2 cycles jrne looptx d //3 cycles so the wait loop duration is (4 + (3 + 2 + 3)* v al1) clock cycles: as a consequence, val1 must be defined as follows: val1= (osc/baud-4) / 8 afterward each bit d (0 d 7) of the data variable is tested one by one. if it is 1, the program jumps to the bit d label. the nop is to have the same execution time for both 1 and 0. btjt data,# d ,bit d //5 cycles //if '0' bres pbdr, #tx //5 cycles jp bit0cnt //2 cycles //if '1' bit01: bset pbdr, #tx //5 cycles nop //2 cycles bit0cnt: 3.3.3 data reception 3.3.3.1 principle data reception is based on an interrupt routine triggered by a falling edge on the rx pin. the falling edge corresponds to the transition idle to start bit. once started, the interrupt routine performs the following tasks: C sample the rx pin again to check the falling edge was not a noise phenomenon. C sample the 1 st bit, 1.5 bit times after the falling edge. C sample the next bits each bit time, and rebuild the complete byte, bit by bit. C check that no new falling edge interrupt has been triggered. C store the byte in the data buffer, pointed to by buffer_rx_ptr C set a flag if the buffer overflows. at the end of the interrupt routine, the firmware checks if the data pattern includes a 1 to 0 transition. this is because this transition generates a pending falling edge interrupt request that does not correspond to a start of bit condition. in order to avoid generating spurious data
15/17 half duplex usb-to-serial bridge using the st72611 usb mcu reception, a flag is set at the end of the interrupt routine if any 1 to 0 transition occurs during data reception. this flag is read at the start of the interrupt routine, and if it is found to be set, the interrupt routine finishes without any data reception. 3.3.3.2 sampling the 1 st data bit as the execution of the interrupt routine takes some time to start, the computation of the 1.5 bit times has to take into account this additional delay. this delay can be due to the completion of the current instruction, or to the completion of the whole usb interrupt routine. the delay has been computed with the following data: time needed to enter usb interrupt routine 34 cycles. 4.25s (use of regx options) time needed to exit usb interrupt & monitor rx 53 cycles, 6.625s (use of regx options) time needed to enter the falling edge interrupt routine 10 cycles, 1.25s time to complete the currently executing instruction 9 cycles, 1.1s execution time of usb interrupt routine 70 cycles 8.75s if... then... the i/o port falling edge event occurs before or 20s after the usb interrupt event. the first instruction of the falling edge it is executed 2.2s after (time to complete the last instruction + time to enter the interrupt routine). no flag set in the usb interrupt routine the falling edge event occurs up to 13s (4.25+8.75) after the usb interrupt event. a flag is set at the end of the usb interrupt routine if the rx line is low. the first instruction of the falling edge interrupt routine is exe- cuted between 8s & 21s after the falling edge. it may m ask the start bit at 57600 bps! * 8s (6.625+1.25) if the falling edge occurs just at the end of the usb interrupt routine. *21s (4.25+8.75+6.625+1.25) if the falling edge occurs just after the usb interrupt event. flag set in the usb interrupt rou- tine. rx sampling for noise immunity is done by monitoring rx in the usb interrupt routine. the falling edge event occurs between 13s and 19.6s after the usb interrupt event. the usb interrupt does not see rx at 0, and no flag is set. the first instruction of the falling edge interrupt routine is executed be- tween 1.25s & 8s after the falling edge. 1.25s if the falling edge occurs just when execution returns to the main routine. 8s (6.625+1.25) if the falling edge occurs just after the end of the usb interrupt routine. no flag set in the usb interrupt routine
16/17 half duplex usb-to-serial bridge using the st72611 usb mcu in summary: if no flag is set, the falling edge occurred between 2.2s and 8s before the start of the falling edge interrupt routine: an average delay of 1.5 bit times C 4s is then chosen. if a flag is set, the falling edge occurred between 8s and 20s before the start of the falling edge interrupt routine: an average delay of 1.5 bit times C 15s is then chosen. with these values, volume data transfer has been performed successfully at 4800, 9600, 19200, 38400 and 57600 bps.
17/17 half duplex usb-to-serial bridge using the st72611 usb mcu the present note which is for guidance only aims at providing customers with information regarding their products in order for them to save time. as a result, stmicroelectronics shall not be held liable for any direct, indirect or consequential damages with respect to any claims arising from the content of such a note and/or the use made by customers of the information contained herein in connection with their products. information furnished is believed to be accurate and reliable. however, stmicroelectronics assumes no responsibility for the co nsequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. no license is granted by implication or otherwise under any patent or patent rights of stmicroelectronics. specifications mentioned in this publicati on are subject to change without notice. this publication supersedes and replaces all information previously supplied. stmicroelectronics prod ucts are not authorized for use as critical components in life support devices or systems without the express written approval of stmicroele ctronics. the st logo is a registered trademark of stmicroelectronics ? 2002 stmicroelectronics - all rights reserved. purchase of i 2 c components by stmicroelectronics conveys a license under the philips i 2 c patent. rights to use these components in an i 2 c system is granted provided that the system conforms to the i 2 c standard specification as defined by philips. stmicroelectronics group of companies australia - brazil - canada - china - finland - france - germany - hong kong - india - israel - italy - japan malaysia - malta - morocco - singapore - spain - sweden - switzerland - united kingdom - u.s.a. http://www.st.com

▲Up To Search▲

Price & Availability of AN1071

	To Download AN1071 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .